Columbia Kermit/kermit.zip/newsgroups/misc.19980901-19981211/000186_news@newsmaster….columbia.edu _Thu Oct 22 19:03:30 1998.msg

Internet Message Format | 2020-01-01 | 4KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA29385
    for <[e-mail]>; Thu, 22 Oct 1998 19:03:30 -0400 (EDT)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id TAA25521
    for kermit.misc@watsun; Thu, 22 Oct 1998 19:03:29 -0400 (EDT)
Path: news.columbia.edu!panix!news-xfer.newsread.com!netaxs.com!newsread.com!newsfeed.direct.ca!xmission!news.cc.utah.edu!cc.usu.edu!jrd
From: [e-mail] (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Stop automatic resetting of terminal emulation?
Message-ID: <[e-mail]>
Date: 22 Oct 98 15:33:43 MDT
References: <[e-mail]>
Organization: Utah State University
Lines: 51
Xref: news.columbia.edu comp.protocols.kermit.misc:9382

In article <[e-mail]>, Andrew J Pardoe <[e-mail]> writes:
> We use K/2 and K-95 heavily to telnet to different applications throughout
> our hospital. We've run into a problem twice where the remote host will
> reset the terminal emulation of the local K-95 just after the remote login
> sequence is completed.
>
> It's not a problem when the VT host changes the emulation from VT320 to
> VT220 but we've run into a conundrum when an SCOANSI host changes the
> emulation from SCOANSI (which works perfectly) to ANSI (which doesn't.)
>
> Two possible solutions present themselves: first, get the host to stop
> sending a request to change terminal emulation; second, set Kermit to
> ignore any requests to change the terminal emulation. Knowing the kind of
> support one receives from Kermit, I decided to start here.
>
> Any suggestions would be appreciated. I couldn't find this addressed in
> the manual(s) or Dejanews so I'm stuck.
>
> Thank you,
>
> Andrew Pardoe
> University of Washington
>
> PS: I realize I can go back to the command line to manually reset the
> terminal emulation to what it was originally and go on my merry way.
> Unfortunately, the many of the people here wouldn't quite understand the
> concept of command line, let alone terminal emulation. Heck, Alt-X is
> probably stretching the computer skills of some...
---------
Andrew,
    Curious that you should bring up the topic because we had gone
over it recently in the project. Let me indicate the two views on the matter.
    First is the IETF view. It says when the remote host asks repeatedly
for a terminal type the client is supposed to offer new kinds in each
response, as a negotiation process. Thus if a remote host does not understand
or accept one kind it asks again and the two sides run down their lists.
Spelling counts for everything here, and no two machines seem to agree
on spelling of terminal names. The RFCs do this haggle stuff.
    The second is my view, which is the negotiation is stupid in the
extreme. When the client responds with a terminal type that's it, there
isn't more to the game. The remote host accepts or copes or rejects. The
reason haggling is so stupid is there is a great deal more concerning
terminal emulation than just the name/kind, and changing the name/kind
upsets all other items associated with the session. Keyboard definitions,
expectations by software at either end, and so on are most often tailored
for specific terminal kinds, and here the IETF says it's fine to negotiate
away that information without a word to the user. Amazing.
    The fix, if we may use that term, is to force the terminal name
in the SET TCP TERM command so only one kind is permitted to be offered,
period.
    Joe D.